Message Handling in an IP Multimedia Subsystem

ABSTRACT

A method and apparatus for handling a Session initiation Protocol communication in an IP Multimedia Subsystem (IMS) network. A Proxy Call Session Control Function receives a Session Initiation Protocol message sent from a trusted remote network. The P-CSCF adds to the message a further header, which identifies a Public User Identity of a trusted entity located in the remote network served by a Serving Call Session Control Function in the IMS network. The message is then sent to the S-CSCF. The S-CSCF, and any other node that the message is sent to, knows from the presence of the further header to use the Public User Identity of the trusted entity to determine the served user rather than the P-Asserted Identity contained in the SIP message.

CROSS-REFERENCE TO RELATED APPLICATIONS

This application is a continuation application of U.S. application Ser.No. 12/812,266, which is the National Stage of International ApplicationNo. PCT/EP2008/050305, filed Jan. 11, 2008. Each of the '266 and '305applications are expressly incorporated herein by reference in theirentirety.

TECHNICAL FIELD

The present invention relates to Session Initiation Protocol messagehandling in a communications network.

BACKGROUND

IP Multimedia Subsystem (IMS) is the technology defined by the ThirdGeneration Partnership Project (3GPP) to provide IP Multimedia servicesover mobile communication networks (3GPP TS 22.228). IMS provides keyfeatures to enrich the end-user person-to-person communicationexperience through the integration and interaction of services. IMSallows new rich person-to-person (client-to-client) as well asperson-to-content (client-to-server) communications over an IP-basednetwork.

The IMS makes use of the Session Initiation Protocol (SIP) to set up andcontrol calls or sessions between user terminals (UEs) or between UEsand application servers (ASs). The Session Description Protocol (SDP),carried by SIP signalling, is used to describe and negotiate the mediacomponents of the session. Whilst SIP was created as a user-to-userprotocol, IMS allows operators and service providers to control useraccess to services and to charge users accordingly.

Within an IMS network, Call/Session Control Functions (CSCFs) operate asSIP entities within the IMS. The 3GPP architecture defines three typesof CSCFs: the Proxy CSCF (P-CSCF) which is the first point of contactwithin the IMS for a SIP terminal; the Serving CSCF (S-CSCF) whichprovides services to the user that the user is subscribed to; and theInterrogating CSCF (I-CSCF) whose role is to identify the correct S-CSCFand to forward to that S-CSCF a request received from a SIP terminal viaa P-CSCF.

IMS service functionality is implemented using application servers(ASs). For any given UE, one or more ASs may be associated with thatterminal. ASs communicate with an S-CSCF via the IMS Service Control(ISC) interface and are linked into a SIP messaging route as required(e.g. as a result of the triggering of iFCs downloaded into the S-CSCFfor a given UE).

A user registers in the IMS using the specified SIP REGISTER method.This is a mechanism for attaching to the IMS and announcing to the IMSthe address giving the location at which a SIP user identity can bereached. In 3GPP, when a SIP terminal performs a registration, the IMSauthenticates the user using subscription information stored in a HomeSubscriber Server (HSS), and allocates an S-CSCF to that user from theset of available S-CSCFs. Whilst the criteria for allocating S-CSCFs arenot specified by 3GPP, these may include load sharing and servicerequirements. It is noted that the allocation of an S-CSCF is key tocontrolling, and charging for, user access to IMS-based services.Operators may provide a mechanism for preventing direct user-to-user SIPsessions that would otherwise bypass the S-CSCF.

During the registration process, it is the responsibility of the I-CSCFto select an S-CSCF, if an S-CSCF is not already selected. The I-CSCFreceives the required S-CSCF capabilities from the HSS, and selects anappropriate S-CSCF based on the received capabilities. It is noted thatS-CSCF allocation is also carried for a user by the I-CSCF in the casewhere the user is called by another party, and the user is not currentlyallocated an S-CSCF. When a registered user subsequently sends a sessionrequest to the IMS, the P-CSCF is able to forward the request to theselected S-CSCF based on information received from the S-CSCF during theregistration process.

Every IMS user possesses one or more Private User Identities. A PrivateUser Identity is assigned by the home network operator and is used bythe IMS, for example for registration, authorisation, administration,and accounting purposes. This identity takes the form of a NetworkAccess Identifier (NAI) as defined in IETF RFC 2486. It is possible fora representation of the International Mobile Subscriber identity (IMSI)to be contained within the NAI for the private identity. 3GPP TS 23.228specifies the following properties of the Private User identity:

-   -   The Private User Identity is not used for routing of SIP        messages.    -   The Private User Identity is contained in all Registration        requests, (including Re-registration and De-registration        requests) passed from the UE to the home network.    -   An IP multimedia Services Identity Module (ISIM) application        securely stores one Private User Identity. It is not possible        for the UE to modify the Private User Identity information        stored on the ISIM application.    -   The Private User Identity is a unique global identity defined by        the Home Network Operator, which may be used within the home        network to identify the user's subscription (e.g. IM service        capability) from a network perspective. The Private User        Identity identifies the subscription, not the user.    -   The Private User Identity is permanently allocated to a user's        subscription (it is not a dynamic identity), and is valid for        the duration of the user's subscription with the home network.    -   The Private User Identity is used to identify the user's        information (for example authentication information) stored        within the HSS (for use for example during Registration).    -   The Private User Identity may be present in charging records        based on operator policies.    -   The Private User Identity is authenticated only during        registration of the user, (including re-registration and        de-registration).    -   The S-CSCF needs to obtain and store the Private User Identity        upon registration and unregistered termination.

In addition to a Private User Identity, every IMS user has one or moreIMS Public User Identities (PUIs). The PUIs are used by any user torequest communications to other users. A user might for example includea PUI (but not a Private User Identity) on a business card. 3GPP TS23.228 specifies the following properties of the PUI:

-   -   Both telecom numbering and Internet naming schemes can be used        to address users depending on the PUIs that the users have.    -   The PUI(s) take the form of a SIP URI (as defined in RFC 3261        and RFC 2396 or the “tel:”-URI format defined in RFC 3966.    -   An ISIM application securely stores at least one PUI (it shall        not be possible for the UE to modify the PUI), but it is not        required that all additional PUIs be stored on the ISIM        application.    -   A PUI is registered either explicitly or implicitly before the        identity can be used to originate IMS sessions and IMS session        unrelated procedures.    -   A PUI is registered either explicitly or implicitly before        terminating IMS sessions and terminating IMS session unrelated        procedures can be delivered to the UE of the user that the PUI        belongs to.    -   It is possible to register globally (i.e. through one single UE        request) a user that has more than one PUI via a mechanism        within the IMS (e.g. by using an Implicit Registration Set).        This does not preclude the user from registering individually        some of his/her PUIs if needed.    -   PUIs are not authenticated by the network during registration.    -   PUIs may be used to identify the user's information within the        HSS (for example during mobile terminated session set-up).    -   PUIs may be used by ASs within the IMS to identify service        configuration data to be applied to a user.

FIG. 1 illustrates schematically example relationships between a user(IMS) subscription and the Public and Private User Identities. In theexample shown, a subscriber has two Private User Identities, with bothbeing associated with two Public User Identities (one of the Public UserIdentities, Public User Identities-2, being associated with both PrivateUser Identities). A Service Profile is associated with each Public UserIdentity, this profile specifying service data for the associated PublicUser Identities. A Service Profile is created or modified when anapplication server is provisioned for a user at the Home SubscriberServer. Each Service Profile comprises one or more initial FilterCriteria (iFCs), which are used to trigger the provision, orrestriction, of IMS services. The differences between services offeredby Service Profile-1 and Service Profile-2 are operator specific, butmay involve different application servers (ASs), and even differentcharging/rating schemes.

In the example shown in FIG. 1, Public User Identity-1 is associatedwith a Service Profile-1, whilst Public User Identity-2 and Public UserIdentity-3 are associated with Service Profile-2. In a typical scenario,the Public User Identity-1 might be an identity that the user gives tofriends and family, e.g. “Big_Joe@priv.operator.com”, whilst Public UserIdentity-2 and Public User Identity-3 might be identities that the usergives to business contacts, e.g. “+46111222333@operatorcom” and“joe.black@operator.com”.

3GPP defines a so-called “Implicit Registration Set” concept to identifya set of PUIs that work as a group, and which are registered andderegistered together when any one of the PUIs of the set is registeredor deregistered. 3GPP requires that the HSS sends the implicitRegistration Set to the S-CSCF upon registration of a user or uponterminating a call. It has been understood that, at registration, theHSS identifies all PUIs within the Implicit Registration Set, and thenidentifies all of the Service Profiles associated with these PUIs. TheService Profiles (or selected data from the Service Profiles) containingthe PUIs with which they are associated are then sent to the S-CSCF. Asa result of this operation, the S-CSCF knows all of the PUIs that belongto the same Implicit Registration Set, as well as their ServiceProfiles.

A possible use case of the IMS involves a collection of users having agroup level subscription to the IMS, but where the individual usersthemselves have no subscription and of which the IMS is unaware. It isdesirable to allow direct inward and outward dialling to the users. Thismight arise, for example, in the case of a company having a subscriptionto the IMS and having individual employee stations or terminals attachedto an IP private branch exchange (IP-PBX). The employee terminals may ormay not be provided with SIP clients. In the latter case, the IP-PBXperforms a translation between SIP and non-SIP signalling. Whilst itmight of course be possible for the IMS to record an individual PUI foreach terminal (within the same Implicit Registration Set), this becomesinefficient as the group size becomes large. ETSI TISPAN defines such acorporate network as a Next Generation Corporate Network (NGCN).

It is possible to include within the Implicit Registration Setassociated with a subscription, a wildcarded Public User Identity.“Wildcarded” or “wildcard” is understood here to mean a Public UserIdentity that contains a symbol or symbol that stands for one or moreunspecified characters. The wildcarded Public User Identity has aservice profile associated with it. Any node within the IP MultimediaSubsystem which performs checks or processing based upon the ImplicitRegistration Set, acts upon a received Public User Identity matching awildcarded Public User Identity in the same way as if the receivedPublic User Identity matched any standard Public User Identity withinthe Implicit Registration Set. Rather than representing a range ofPublic User identities using a wildcarded Public User Identity, such arange may instead be represented by a sub-domain. For example, a rangeof Tel URIs may be represented by a dialing prefix, whilst a range ofSIP URIs may be represented by a corporate domain. This allows routingto and from corporate network users when the corporate network isconnected to an IMS network over the Gm reference point.

However, there is a requirement in the TISPAN published specificationfor Business Communication Requirements (ETSI TS 181 019 (V2.0.0).Telecommunications and Internet converged Services and Protocols forAdvanced Networking (TISPAN); Business Communication Requirements)] thatexpresses that the operator's trust domain should be able to be extendedinto the corporate network domain where a business trunk between an IMSnetwork and a trusted corporate network is in place. An implication ofthis is that the P-CSCF in the IMS network must accept aP-Asserted-Identity header sent from the corporate network over the Gmreference point. The P-Asserted-Identity header is a header in a SIPmessage that contains a SIP URI and an optional display-name. TheP-Asserted-Identity is an identity that is used among trusted SIPentities, typically intermediaries, to carry the identity of the usersending a SIP message as it was verified by authentication. TheP-Asserted-Identity is inserted into the header field of a SIP messageby a SIP entity once the node has authenticated the originating user insome way. A consequence of this is that the P-Asserted-Identity may notrepresent the originating served user of the IMS network, as theP-Asserted-Identity contains an identity that is authenticated by theremote/corporate/private network.

The S-CSCF normally uses the P-Asserted-Identity to check whether anyrelevant restrictions have been placed on the originating UE, e.g. isthe UE barred from using the requested service. The S-CSCF also uses theP-Asserted-Identity and call case to determine the Initial FilterCriteria (IFCs) for the UE. Assuming, for example, that the IFCs requirethat the S-CSCF forward the INVITE to a particular AS, the S-CSCFincludes at the topmost level of the SIP route header the URI of the AS.It also includes in the subsequent level its own URI, together with anOriginal Dialog Identifier (ODI). The ODI is generated by the S-CSCF anduniquely identifies the call to the S-CSCF. The AS will itself performauthentication based upon the P-Asserted-Identity contained in themessage. It can be concluded from this that the P-Asserted-Identity isused in an originating IMS network to determine the served user, for thenetwork to be able to execute the right policies/services for this user.

As described above, when the trust domain is extended from a public IMSnetwork into another network connected over a Gm reference point, theP-Asserted-Identity can contain a user identity not known in the IMSnetwork. However, a problem arises because the P-Asserted-Identity isalso used by originating IMS core systems to determine the served user.When forwarding a message containing a P-Asserted-Identity of a userthat does not represent the user currently served by a P-CSCF, and insome cases a P-Asserted-Identity that is not the identity of a known IMSuser, the current procedures would either fail, procedures would beexecuted for the wrong user, or the P-CSCF would drop theP-Asserted-Identity belonging to a different user.

SUMMARY

The inventor has devised a method to allow an IMS network to extend itstrust domain to another network. A P-CSCF in the IMS network, afterreceiving a SIP message from the trusted company domain, inserts a newheader, termed a P-Served-User header, in the SIP message before sendingthe SIP message to an S-CSCF. Optionally the P-CSCF only inserts the newheader when the P-Asserted-Identity in the SIP message does not match anidentity of an implicit Registration set belonging to the trustedentity. The P-Served-User header includes the identity of the serveduser. The identity of the served user is a default identity belonging tothe trusted network site through which the SIP message entered the IMSnetwork. An S-CSCF that subsequently receives the SIP message is thenaware that it must use the P-Served-User header field to determine theserved user and it can ignore a P-Asserted-Identity header field for thepurpose of determining the served user.

According to a first aspect of the invention, there is provided a methodof handling a Session Initiation Protocol (SIP) communication within anIP Multimedia Subsystem (IMS) network. A Proxy Call Session ControlFunction (P-CSCF) receives a SIP message sent from a remote network. TheP-CSCF adds to the message a further header, which identifies a PublicUser Identity of a trusted entity in the remote network served by aServing Call Session Control Function in the IMS network. Optionally theP-CSCF only inserts the new header when the P-Asserted-Identity in theSIP message does not match the identity of the trusted entity. ThePublic User Identity of the trusted entity is optionally obtained bydetermining the identity of a secure channel on which message wasreceived. The message is then sent to the S-CSCF. The S-CSCF, and anyother node that the message is sent to, knows from the presence of thefurther header to ignore the contents of a P-Asserted-Identity header,which may not include the identity of the user Public User Identityserved by the S-CSCF, and instead to use the Public User Identity of thetrusted entity contained in the further header.

The SIP message is optionally sent via a business trunk between theremote network and the IMS network, and the remote network is trusted bythe IMS network. Because the IMS network's P-CSCF trusts the remotenetwork (this can be termed being in the same trustdomain, see IETF RFC3324 and RFC 3325) it will trust the P-Asserted-Identity received fromthat network, and nodes within the IMS network which trust the P-CSCFwill trust the P-Asserted-Identity received from it and so on. This istermed transitive trust. Nodes in the IMS network will therefore beaware that the trusted entity can be trusted.

Optionally, the further header identifying the private network node isobtained from subscription information relating to the Public UserIdentity of the trusted entity stored at either a Home Subscriber Serveror, in the case of a NGN network, a User Profile Server Function locatedin the IP Multimedia Subsystem network.

The subscription information relating to the Public User Identity of thetrusted entity optionally includes an Implicit Registration Set.Optionally an Implicit Registration Set includes a wildcarded PublicUser Identity or Public User Identity sub-domain representative of arange of Public User Identities. As a further option, the SIP message isa SIP INVITE message sent from the trusted entity on behalf of a user ofthe remote network.

According to a second aspect of the invention, there is provided aP-CSCF node for use in an IMS network. The P-CSCF Function nodecomprises a receiver for receiving a SIP message sent from a remotenetwork. A processor is provided for adding to the message a furtherheader, the further header identifying a Public User Identity of atrusted entity in the remote network that is served by a S-CSCF. TheP-CSCF also includes a transmitter for sending the message to theS-CSCF. The further header can be used by other nodes in the IMS networkto inform them to use information in the further header to identify theserved node, rather than information contained in theP-Asserted-Identity header.

The P-CSCF optionally comprises means for receiving subscriptioninformation relating to the Public User Identity of the trusted entityfrom one of a Home Subscriber Server and a User Profile Server Functionlocated in the IMS network.

The subscription information optionally includes an ImplicitRegistration Set, the Implicit Registration Set comprising a wildcardedPublic User Identity or Public User Identity sub-domain representativeof a range of Public User Identities.

According to a third aspect of the invention, there is provided a S-CSCFnode for use in an IMS network. The S-CSCF node comprises a receiver forreceiving a Session Initiation Protocol message from a P-CSCF node, anda processor for identifying the presence of a further header in theSession Initiation Protocol message, the further header identifying aPublic User Identity of a trusted entity in a remote network served bythe Serving Call Session Control Function. The S-CSCF also includesmeans for, in the event that the further header is identified, using thePublic User Identity of the trusted entity in that header to determinethe served user instead of the P-Asserted-Identity header contained inthe SIP message. In this way, messages received by the S-CSCF in whichthe served user is not identified by the P-Asserted-Identity header canbe dealt with properly.

According to a fourth aspect of the invention, there is provided anApplication Server (AS) for use in an IMS network. The AS comprises areceiver for receiving a SIP message, and a processor for identifyingthe presence of a further header in the Session Initiation Protocolmessage. The further header identifies a Public User Identity of atrusted entity in a remote network served by a S-CSCF in the IMSnetwork. The AS further includes means for, in the event that thefurther header is identified, using the Public User Identity of thetrusted entity contained in that header to determine the served userinstead of the P-Asserted-Identity.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 illustrates schematically example relationships between a userIMS subscription and Public and Private User Identities;

FIG. 2 illustrates schematically in a block diagram a signalling flowbetween a corporate network and an IMS network according to anembodiment of the invention;

FIG. 3 is a flow diagram showing the basic steps of an embodiment of theinvention;

FIG. 4 illustrates schematically in a block diagram a P-CSCF accordingto an embodiment of the invention;

FIG. 5 illustrates schematically in a block diagram an S-CSCF accordingto an embodiment of the invention;

FIG. 6 illustrates schematically in a block diagram an ApplicationServer according to an embodiment of the invention.

DETAILED DESCRIPTION

Referring to FIG. 2, there is illustrated schematically an IMS network 1and a trusted corporate network 2. The corporate network 2 contains aPrivate Branch Exchange (PBX), denoted IP-PBX. The IP-PBX registers withthe IMS network 1 on behalf of a group of user terminals. IP-PBX learnsthe address of the outbound P-CSCF 3 located in the IMS network 1 by wayof a DHCP lookup (as specified in IETF RFC 3263). IP-PBX registers withthe IMS network using its own PUI (in this example,“pbx1@operator.com”). An HSS 4 in the IMS network 1 stores subscriptioninformation for IP-PBX, which includes an Implicit Registration Set thatincludes all users able to access the IMS network 1 via IP-PBX. Inaddition to IP-PBX's PUI and a tel URI allocated to IP-PBX, the ImplicitRegistration Set contains a “wildcard” PUI which represents a range ofPUIs associated with the PBX. In this example, the wildcard PUI is“!x!@enterprise2.com”. The “!x!” component of the wildcard PUI indicatesthat a PUI having the specified suffix and any prefix will match thewildcard PUI.

The HSS 4 sends the Implicit Registration Set to an S-CSCF 7 in a ServerAssignment Answer together with the associated service profile(s). TheS-CSCF 7 then sends a 200 OK message to IP-PBX via the I-CSCF (notshown) and the P-CSCF 3, with the 200 OK message including aP-Associated-URI field identifying the PUIs within the ImplicitRegistration Set associated with the PUI of the PBX.

Considering the case where a terminal in the trusted corporate networkwishes to forward a call to another terminal, a first terminal 5 havingthe identity Cassandra@enterprise3.com calls a second terminal 6 havingthe identity Bob@enterprise2.com. A message sent from the first terminal5 contains in its header the URI Cassandra@enterprise3.com in the “From”field and Bob@enterprise2.com in the “To” field. The message alsoincludes the P-Asserted-Identity of Cassandra@enterprise3.com. However,messages sent to Bob@enterprise2.com are to be forwarded toAlice@enterprise1.com.

The message is returned to IP-PBX for forwarding toAlice@enterprise1.com, and IP-PBX determines that this must be sent tothe P-CSCF 3 in the IMS network 1. IP-PBX sends an INVITE message to theP-CSCF 3, the invite message containing the URI for Alice, the URI forCassandra in the “From” field, and the URI for Bob in the “To” field.The INVITE also contains Cassandra's P-Asserted-Identity.

Note that a trust relationship exists between the IP-PBX in thecorporate network 2 and the IMS network 1. Because the P-CSCF 3 receivesthe SIP INVITE on the security association that was created duringregistration, the P-CSCF is aware that the INVITE is to be treated onbehalf of pbx1@operator1.com. The P-CSCF 3 is also aware that the trustdomain of the IMS network 1 extends to IP-PBX in the corporate network2. The P-CSCF 3 passes the P-Asserted-Identity unmodified and inserts anew header to the INVITE, the new header referred to as the“P-Served-User”. The P-Served-User header contains the URI of IP-PBX,that is pbx1@operator1.com. Note that in one embodiment, the P-CSCF 3will only insert a P-Served-User header in the event that theP-Asserted-Identity does not match the identity from which the messagewas received. In this example, the P-CSCF will only insert aP-Served-User header if the P-Asserted-Identity is not an element of theImplicit Registration Set belonging to the trusted entity.

The P-CSCF 3 forwards the SIP INVITE containing the P-Served-User headerto the S-CSCF 7. The IFCs associated with pbx1@operator.com subscriptionmay indicate that the INVITE is to be processed by a call forwardingApplication Server (AS) 8. In this case, the S-CSCF 7 performs standardoperations of adding the SIP URI of the AS 8 as the topmost URI of theroute header, and including its own SIP URI beneath the AS URI in theroute header together with the “original dialog identifier” (ODI). Themessage is then forwarded to the AS 8 over the ISC interface. The S-CSCF7 maintains state information for the session to which the INVITErelates. This information includes the ODI and the identity of theserved User.

The S-CSCF 7 also determines the served user based upon theP-Served-User, rather than the P-Asserted-Identity. This allowsauthentication to be based on the IP-PBX identity associated withIP-PBX, rather than the P-Asserted-Identity contained in the SIP INVITE.

If the P-Served-User header were not included in the SIP INVITE, nodesin the IMS network would attempt to perform authorisation on theP-Asserted-Identity (in this case, Cassandra@enterprise3.com). AsCassandra@enterprise3.com does not belong to the IMS network or theattached corporate network, authentication using the P-Asserted-Identitywould fail.

The invention allows the P-CSCF 3 to communicate the served user(Bob@enterprise2.com) in a separate information element in the SIPINVITE from the identity of the network asserted originating user(Cassandra@enterprise3.com). The S-CSCF 7 uses this to determine theserved user. This allows corporate networks to be treated as trustednetworks.

FIG. 3 is a flow diagram illustrating the basic steps of an embodimentof the invention. The following numbering refers to the numbering inFIG. 3:

-   -   S1. The P-CSCF receives a SIP message from IP-PBX on the        security association created during registration;    -   S2. By receiving the SIP message on the existing security        association and recognising this is coming from a trusted        entity, and determining that the P-Asserted-Identity does not        belong to the set of implicitly registered identities, the        P-CSCF adds the URL of IP-PBX to the SIP message in the form of        a P-Served-User header and leaves an optionally existing        P-Asserted-Identity header intact, as the IP-PBX has a        subscription with the IMS network and the network asserted        originating user may not have such a subscription;    -   S3. The SIP message resulting from step 2 is sent to the S-CSCF;    -   S4. The S-CSCF, being aware of the presence of the P-Served-User        header, ignores the P-Asserted-Identity and uses the        P-Served-User header to determine the served user for processing        of its procedures. If IFCs are activated for the served user,        the SIP message may be forwarded to an AS;    -   S5. If the message is subsequently received by an AS, the AS,        being aware of the presence of the P-Served-User header, uses        the P-Served-User header to determine the served user for        processing relevant procedures.

FIG. 4 illustrates schematically a P-CSCF 3 according to an embodimentof the invention. The P-CSCF 3 comprises a receiver 9 for receiving fromIP-PBX a SIP message. A memory 10 is provided for storing subscriptioninformation relating to IP-PBX, and a processor 11 is provided foradding a P-Served-User header to the SIP message, the P-Served-Userheader identifying the subscription relating to IP-PBX. A transmitter 12is also provided for sending the SIP message to a further node such asan S-CSCF.

FIG. 5 illustrates schematically a S-CSCF 5 according to an embodimentof the invention. The S-CSCF 7 comprises a receiver 13 for receiving aSIP message from the P-CSCF 3, and a processor 14 for determining if theSIP message contains a P-Served-User header. If a P-Served-User headeris present in the SIP message, then the P-Served-User header will beused to determine the served user instead of the P-Asserted-Identity. Atransmitter 15 is also provided for sending the message to other nodesin the IMS network for further processing.

FIG. 6 illustrates schematically an AS 8 according to an embodiment ofthe invention. The AS 8 comprises a receiver 16 for receiving a SIPmessage, and a processor 17 for determining if the SIP message containsa P-Served-User header. If a P-Served-User header is present in the SIPmessage, then the P-Served-User header will be used to determine theserved user instead of the P-Asserted-Identity header. The AS also has atransmitter 18 for sending messages to other nodes in the IMS network.

It will be appreciated by the person of skill in the art that variousmodifications may be made to the embodiments described above withoutdeparting from the scope of the present invention. For example, theabove description refers to an IP_PBX node in a corporate network.However, the invention also applies to a connected SIP proxy node or SIPB2BUA disposed in corporate networks or other types of network.

1. A method of handling a Session Initiation Protocol communicationwithin an IP Multimedia Subsystem network, the method comprising: at aProxy Call Session Control Function, receiving a Session InitiationProtocol message sent from a remote network; at the Proxy Call SessionControl Function, adding to the message a further header, the furtherheader identifying a Public User Identity of a trusted entity in theremote network served by a Serving Call Session Control Function; andsending the message to the Serving Call Session Control Function.